REMARKS/ARGUMENTS 



Claims 1-30 are pending in the present application. With this amendment, claims 5, 15, and 25 
have been canceled; and claims 1-4, 6-14, 16-24, and 26-30 have been amended. Reconsideration of the 
claims is respectfully requested. 

I. 35 U.S.C. g 112. Second Paragraph 

The Examiner has rejected claims 1-30 under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter, which applicants 
regard as the invention. Applicants have amended claims 1,11, and 21. This rejection is believed to be 
overcome by these amendments to the claims, and should be withdrawn. 

II. 35 U.S.C. S 102, Anticipation 

The Examiner has rejected claims 1-5, 8-15, 18-25 and 28-30 under 35 U.S.C. § 102(e) as being 
anticipated by Clemens et al., Payment Management . U.S. Patent Application Publication No. US 
2002/01 11915, published August 15, 2002 (hereinafter referred to as "Clemens"). This rejection, as it 
might be applied to the claims as amended, is respectfully traversed. 

Applicants have amended claims 1,11, and 21. Claim 1 is representative of claims 1 1 and 21. 
Claim 1 now recites: A method in a host data processing system for providing electronic business 
functions for a plurality of business clients, the method comprising: providing, within the host, a first 
software facility for a first one of the plurality of business clients, the first software facility including first 
software facility first and second level services; providing, within the host, a second software facility for a 
second one of the plurality of business clients, the second software facility including second facility first 
and second level services; said host providing web hosting for said first and second ones of the plurality 
of business clients using said first software facility first and second level services and said second 
software facility first and second level services; automatically determining, by the first software facility, 
that a transaction needs to be executed between the first software facility and the second software facility, 
the determination is being made in response to a request from the first one of the plurality of business 
clients; said first software facility making decisions on behalf of the first one of the plurality of business 
clients to execute transactions with the second software facility; the first and second software facilities 
automatically completing the transaction without any action required by either the first one or the second 
one of the plurality of business clients, and parameters defining the bounds in which the transaction takes 
place being determined by the first one of the plurality of business clients. 
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Applicants claim automatically determining, by the first software facility, that a transaction needs 
to be executed between the first software facility and the second software facility, said first software 
facility making said determination on behalf of the first one of the plurality of business clients. The 
determination is not made in response to a request from the first business client. Clemens does not teach 
this feature. Therefore, Clemens does not anticipate Applicants' claims. 

Clemens teaches "In one configuration, the invention is directed to a computer processor 
implemented method of effecting a payment intended for a payee from a payor, whereby a payment 
request is received indicating that the payor has authorized payment to the payee." Clemens, paragraph 
0008. Clemens teaches the payment manager receiving a payment request. See Clemens, Figure 3, step 
52. 

Clemens also describes requesting the payment manager 20 to make a payment in paragraph 0091 

which is reproduced below: 

[0091] Upon receiving a payment request, payment manager 20, through 
payment selection system 32, may configure payment accounts and instructions 144 by 
applying rules stored in customer database 44 to information received with the payment 
request, or may configure a payment transaction based on the instructions contained in 
the payment request. Initially, payment selection system 32 may attempt to configure the 
transaction and determine if it is invalid, non-standard, or a proper configuration. If the 
transaction is invalid, for example, if customer rules do not allow for a proper payment 
configuration, no available account can be identified, required information is not 
supplied, or another irregularity is identified in the payment request, payment selection 
system 32 may send a message 146 to the initiator indicating that the transaction is 
invalid. If the transaction is non-standard, for example, if payment configuration 
instructions are received within the payment request but do not conform to customer 
rules, payment selection system 32 may send a message 148 to customer service system 
36, to cause additional processing to resolve payment configuration. In either event, 
payment selection system 32 may request reconfiguration of the payment instructs 149. 

In contradistinction, Applicants claim the first software facility within the host making the 
determination that a transaction needs to be executed. A request is not received by the first software 
facility from the first business client. Because Clemens teaches the payment manager receiving a request 
to make a payment, Clemens does not anticipate Applicants' claims. 

Clemens also teaches a payment manager 20 first receiving a payment authorization that causes it 
to execute a payment from a payor 4 to a payee 6. The authorization to make a payment can come 
directly from the payor 4, or indirectly through an agent of the payor, through an automated payment 
authorizer, through a marketplace, or by other means. See Clemens, paragraph 0045. 

Clemens does not teach a facility within the payment manager making the determination to make 
a payment. The decision to authorize a payment does not come from the payment manager itself. The 
decision to make a payment, is made outside the payment manager. Once the decision to authorize a 
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payment is made, an authorization is given to the payment manager. Once the authorization is given to 
the payment manager, the payment manager then completes the payment. The decision to make a 
payment, and the authorization to make a payment, occur outside the payment manager. 

Clemens depicts the authorization in Figure 2. The payment manager 20 receives an 
authorization 28. Authorization 28 comes from a source that is external to payment manager 20. 
Furthermore, Clemens does not describe where decision to authorize the payment is made. 

Applicants' claims also describe automatically determining that a transaction needs to be 
executed. Clemens does not teach automatically determining that a transaction needs to be executed. In 
Clemens, a payment is made when a request is received. 

Because Clemens does not teach automatically determining, by the first software facility, that a 
transaction needs to be executed between the first software facility and the second software facility, said 
first software facility making said determination on behalf of the first one of the plurality of business 
clients, Clemens does not anticipate Applicants' claims. 

Applicants also claim said first software facility making decisions on behalf of the first one of the 
plurality of business clients to execute transactions with the second software facility. Clemens does not 
teach this feature. The payment manager does not make decisions on behalf of the payor to execute the 
transaction with the payee. Therefore, Clemens does not anticipate Applicants' claims. 

Clemens does not teach the payment manager including a software facility for a business client 
that makes decisions on behalf of the business client to execute transaction. 

Clemens does not teach the first and second software facilities automatically completing the 
transaction without any action required by either the first one or the second one of the plurality of 
business clients. In Clemens, a request is needed. Therefore, the transaction is not completed within any 
action required. 

Therefore, the rejection of claims 1-5, 8-15, 18-25 and 28-30 under 35 U.S.C. § 102(e) as being 
anticipated by Clemens has been overcome. 

III. 35 U.S.C. S 103, Obviousness 

The Examiner has rejected claims 6, 7, 16, 17, 26 and 27 under 35 U.S.C. § 103(a) as being 
unpatentable over Alnwick, Method and System for Ordering Items Over the Internet , U.S. Patent 
Application Publication No. 2002/00073 1 8, published January 17, 2002. This rejection, as it might be 
applied to the claims as amended, is respectfully traversed. 

In paragraph 9, the Examiner states that the claims are rejected as being unpatentable over 
Alnwick. In the body of the rejection, however, the Examiner refers to both Alnwick and Clemens. 
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Therefore, it appears that the Examiner has rejected the claims as being unpatentable over Clemens in 
view of Alnwick. Applicants' remarks will be directed to the combination of Clemens and Alnwick. 

Applicants respectfully disagree that the combination of Clemens and Alnwick teaches or suggests 
Applicants' claims. 

As discussed above, Clemens does not teach or suggest automatically determining, by the first 
software facility, that a transaction needs to be executed between the first software facility and the second 
software facility, the determination is being made in response to a request from the first one of the 
plurality of business clients; said first software facility making decisions on behalf of the first one of the 
plurality of business clients to execute transactions with the second software facility; the first and second 
software facilities automatically completing the transaction without any action required by either the first 
one or the second one of the plurality of business clients. The Examiner relies on Alnwick to cure the 
deficiencies of Clemens. Alnwick does not cure the deficiencies of Clemens, however, because Alnwick 
does not teach automatically determining, by the first software facility, that a transaction needs to be 
executed between the first software facility and the second software facility, the determination is being 
made in response to a request from the first one of the plurality of business clients; said first software 
facility making decisions on behalf of the first one of the plurality of business clients to execute 
transactions with the second software facility; the first and second software facilities automatically 
completing the transaction without any action required by either the first one or the second one of the 
plurality of business clients. The combination of Clemens and Alnwick does not teach the features of 
Applicants' claims. Therefore, the rejection of claims 6, 7, 16, 17, 26 and 27 under 35 U.S.C. § 103(a) 
has been overcome. 
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It is respectfully urged that the subject application is patentable over Clemens and Alnwick and is 
now in condition for allowance. 

The examiner is invited to call the undersigned at the below-listed telephone number if in the 
opinion of the examiner such a telephone conference would expedite or aid the prosecution and 
examination of this application. 



DATE: April 24, 2007 

Respectfully submitted, 



/Lisa L.B. Yociss/ 



Lisa L.B. Yociss 
Reg. No. 36,975 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 
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